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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp) . 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in SR 000 314 (or the updates on the ETSI Web server) 
which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by Joint Technical Conmiittee (JTC) Broadcast of the European 
Broadcasting Union (EBU), Comite Europeen de Normalisation ELECtrotechnique (CENELEC) and the European 
Telecommunications Standards Institute (ETSI). 

The present document is based on the DVB document TM1324, rev. X / 162 rev. 13, and it may be converted into a 
standard after market feedback. For this purpose, the wording of a standard (normative elements) rather than of a 
technical report (informative elements) has been used. 

NOTE: The EBU/ETSI JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the 
specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body 
by including in the Memorandum of Understanding also CENELEC, which is responsible for the 
standardization of radio and television receivers. The EBU is a professional association of broadcasting 
organizations whose work includes the co-ordination of its members' activities in the technical, legal, 
programme-making and programme-exchange domains. The EBU has active members in about 60 
countries in the European broadcasting area; its headquarters is in Geneva. 

European Broadcasting Union 

CH-1218 GRAND SACONNEX (Geneva) 

Switzerland 

Tel: +41 22 717 21 11 

Fax: +4122 717 24 81 

Founded in September 1993, the DVB Project is a market-led consortium of public and private sector organizations in 
the television industry. Its aim is to establish the framework for the introduction of MPEG-2 based digital television 
services. Now comprising over 200 organizations from more than 25 countries around the world, DVB fosters 
market-led systems, which meet the real needs, and economic circumstances, of the consumer electronics and the 
broadcast industry. 
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1 Scope 

The present document supplements the following documents: 

European Norm (EN) EN 300 468 [1] which describes the Service Information (SI) to be used with Digital 
Video Broadcasting (DVB) systems; 

EN 301 192 [2] which describes mechanisms for the delivery of generic data through DVB bitstreams; 

TS 101 812 [3] and TS 102 812 [4] which describe the DVB's Multimedia Home Platform (MHP). 

The present document identifies the codes allocated for SI, data broadcasting and MHP in DVB systems. The following 
sets of code values are identified: 

the Original_Network_id used to identify the original network (DVB -SI); 

the Network_id used to identify a network (DVB -SI); 

the Bouquet_id used to identify a bouquet (DVB -SI); 

the CA_system_id used to identify the kind of encryption used (DVB -SI); 

the Country code used to identify a country or region (DVB -SI); 

the Private_data_specifier values used to identify a private SI system (DVB -SI); 

the Data_Broadcast_id used to identify a data broadcast specification (DVB -DATA); 

the Platformjd used to identify the IP/MAC platform in use (DVB -DATA); 

the CP_system_id used to identify the copy protection system (DVB -SI); 

the Encoding_type_id used to identify string encodings (DVB -SI); 

the Generic Stream Transport Layer Signaling used to identify the protocol syntax in the payload of Generic 
Streams (DVB-GSE). 

These codes are allocated by the DVB Project at the request of potential service providers and once allocated, become 
part of EN 300 468 [1] by reference. Further details can be obtained by contacting DVB Services Sari. 
( http://www.dvbservices.com) 

DVB Services Sari 

c/o EBU L'Ancienne Route 17a 

CH-1218 Grand-Saconnex 

Switzerland 

Tel: +41 22 717 27 19 

Email: info@dvbservices.com 

Web: http://www.dvbservices.com 
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References 



References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 
cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http ://docbox . etsi . or g/Ref erence . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI EN 300 468: "Digital Video Broadcasting (DVB); Specification for Service Information (SI) 

in DVB systems". 

[2] ETSI EN 301 192: "Digital Video Broadcasting (DVB); DVB specification for data broadcasting". 

[3] ETSI TS 101 812: "Digital Video Broadcasting (DVB); Multimedia Home Platform (MHP) 

Specification 1.0.1". 

[4] ETSI TS 102 812: "Digital Video Broadcasting (DVB); Multimedia Home Platform (MHP) 

Specification 1.1". 

[5] ISO 3166-1: "Codes for the representation of names of countries and their subdivisions ~ 

Part 1: Country codes". 

[6] ETSI TS 102 606: "Digital Video Broadcasting (DVB);Generic Stream Encapsulation (GSE) 

Protocol". 

[7] CENELEC EN 50221: "Common Interface Specification for Conditional Access and other Digital 

Video Broadcasting Decoder Applications". 

[8] ETSI TS 102 006: "Digital Video Broadcasting (DVB); Specification for System Software Update 

in DVB Systems". 

2.2 Informative references 

The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

[i.l] ETSI ETR 162: "Digital Video Broadcasting (DVB); Allocation of Service Information (SI) codes 

for DVB systems". 
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3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in EN 300 468 [1], 
EN 301 192 [2] and the following apply: 

applicant: organistaion which applies for an identifier under the regime of the present document 

registrar: organization who keeps a public register of DVB -SI identifiers and assigns new values to Applicants under 
the regime of the present document 

NOTE: The DVB Project is the only Registrar for DVB-SI identifiers. The DVB Project may pass this task on to 
one or more third parties. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 



CA 


Conditional Access 


CP 


Copy Protection 


CPCM 


Content Protection and Copy Management 


DVB 


Digital Video Broadcasting 


IP 


Internet Protocol 


IPDC 


Internet Protocol Datacasting 


MAC 


Medium Access Control 


MHP 


Multimedia Home Platform 


MMDS 


Multichannel Multipoint Distribution Service 


SI 


Service Information 


TS 


Transport Stream 



Principles of registration 



The present document defines the allocation of identifiers pertaining to different DVB specifications (e.g. MHP, SI, 
Data Broadcasting, etc.). It does not describe the detail or the template as to how this should be done. The aim of the 
present document is to provide assistance to those soliciting and allocating identifiers. 

Each identifier has the following attributes: 

1) It is defined in a DVB specification (e.g. DVB Service Information (EN 300 468 [1])). 

2) It is a binary number represented by its hexadecimal equivalent denoted by the prefix "Ox". 

3) It has a text description. It is the table of values and descriptions which is published on www.dvb.org and/or 
www.dvbservices.com 

4) It is allocated to an organization operating in the digital television space (e.g. ACME Digital Broadcasting, 
Inc.), or a grouping of such companies (e.g. a ACME - Association of Cable/MMDS Enterprises) or an 
institution acting in digital television, e.g. IEEE (Institute of Electrical and Electronic Engineers). 

5) It may be allocated for a given region. For terrestrial broadcasting, this is typically a sovereign country; for 
satellite operations, this is typically a geographical region spanning many countries, but consistent with the 
footprint of the satellites owned by the operators. 

The present document describes where to find definitions of each identifier, who to refer to when there are questions, 
templates for the allocations and rules governing them. In addition, and where appropriate, there are descriptions of best 
practice and some historical notes. 
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The DVB Project shall be the only Registrar entitled to accept applications and perform registrations under the regime 
of the present document and within the application area of EN 300 468 [1]. The DVB Project shall maintain a public, 
on-line register of assigned identifiers to ease quick look-up of the current assignments. 

NOTE: For practical reasons, the DVB Project may choose to delegate the operation and maintenance of the 

public, on-line register and the authority of receiving applications and performing registrations to one or 
more third parties. 



5 Register of Service Information (SI) codes 

5.1 Original Network identification coding 

Original_network_id values shall be allocated to broadcasters, network operators and content producers to uniquely 
identify networks within the application area of EN 300 468 [1], by insertion in the original_network_id field. 

Table 1: Original_network_id registration template 



Reistration field 


Required 


Description 


Original Network ID 


optional 


ID according to the template below 


Original Network Name 


required 


Name of the Network (e.g. "ACME TV") 


Original Network Operator 


required 


Name of company which operates network 
(e.g. "ACME Broadcast Corp.") 


Original Network Legal Contact 


required 


Name and e-mail of authorized legal signatory of 
"Original Network Operator" 


Original Network Technical Contact 


required 


Name and e-mail of technical contact of "Original 
Network Operator" 


Original Network Notes 


optional 


Notes on the application, e.g. last revised and what 
revisions were made 



The Original network ID field in the registration template is to be seen as a proposal by the Applicant. The Registrar is 
not required to follow this suggestion and may assign a different value. In this case, the Applicant should be provided 
with a rationale for not having assigned the proposed bouquet_id value. 

The rules for the allocation of original_network_ids are as follows: 

1) In principle only one original_network_id would be assigned to each network operator, broadcaster or content 
producer. 

2) Original_network_ids are a scarce resource and their allocation is under responsibility of the Registrar. 
Application of multiple original_network_ids is subject to exhaustive verification and discouraged. 

3) 256 original_network_ids values are reserved for private/temporary use. Their allocation is not subject of the 
ETSI standard. 

NOTE: The concept of distinction between the allocation of Original_Network_id and Network_id is new since 
edition 1 of ETR 162 [i.2]. The introduction of this concept was necessary because the address space for 
Network_ids and Original Network_ids was limited to 65 535 values and it was considered that terrestrial 
networks and cable networks might require a large number of Network_ids. 

Since these networks have in most cases a clearly identified geographical region of validity, the re-usage 
of Network_ids is possible. However, Original_Network_ids have to be unique independent of 
geographical region, since they are used to uniquely identify the transport streams and services. 

In terrestrial networks, however it is recommended that all operators within a country use the same 
original_network_id. This implies that broadcasters and operators within a country would need to 
coordinate the allocation of transport_stream_ids and service_ids between them. The Registrar is 
recommended to allocate original_network_id values for terrestrial operators on the basis of 
country_code + 0x2000. This will help receivers to discriminate broadcasts from multiple countries. 
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As a consequence, the present document contains one table for the unique identification of 
Original_Network_ids and another table for the identification of unique and re-usable Network_ids. In 
order to explain the matter some examples are given in annex A. 

The values given in table 2 are to be used to identify networks within the application area of EN 300 468 [1], by 
insertion in the field original_network_id. 

Table 2: Original_network_id allocation template 



Original network id 


Description 


Operator 


0x0000 


Reserved 


Reserved 


0x0001 to OxFEBF 


Reserved for general registration through the DVB Project 
(see httD:/www.dvb.ora) 


OxFECO to OxFFOO 


Network Interface IVIodules 


DVB Common Interface [7] 


OxFFOO to OxFFFF 


Private_temporary_use 





5.2 Network identification coding 



Network_id values shall be allocated to broadcasters and network operators to identify networks within the application 
area of EN 300 468 [1], by insertion in the network_id field. 

A network is defined as a collection of MPEG 2 Transport Stream (TS) multiplexes transmitted on a single delivery 
system, e.g. all digital channels on a specific cable system. Network_IDs are unique within the geographical region 
defined by the country_code: 

• For satellite networks, this is a region spanning many countries. 

• For a cable network, this is a single country. 

• For terrestrial networks, this is a single country also, but it iss important that two adjacent countries shall not 
have the same block of Network IDs. Hence the concept of colour coding countries was introduced. 

Table 3: Networkjd registration template 



Reistration field 


Required 


Description 


Network ID 


optional 


ID according to the template below 


Network Type 


required 


Satellite, terrestrial or cable 


Network Name 


required 


Name of the Bouquet (e.g. "ACME Cable") 


Network Country Code 


required 


Country code where the bouquet is unique (e.g. "North 
America") 


Network Operator 


required 


Name of company which operates the network (e.g. 
"ACME Pay-TV, Inc.") 


Network Legal Contact 


required 


Name and e-mail of authorized legal signatory of 
"Bouquet Operator" 


Network Technical Contact 


required 


Name and e-mail of technical contact of 
"Bouquet_Operator" 


Network Notes 


optional 


Notes on the application, e.g. last revised and what 
revisions were made 



The Network ID field in the registration template is to be seen as a proposal by the Applicant. The Registrar is not 
required to follow this suggestion and may assign a different value. In this case, the Applicant should be provided with 
a rationale for not having assigned the proposed network_id value. 

The rules for the allocation of network_ids are as follows: 

1) Network_ids will be allocated on a geographical basis such that no conflict of network ids occurs in any 
geographical region. (Satellite network ids will be unique world-wide). 

2) Network_ids are a scarce resource and their allocation is under responsibility of the Registrar. Application of 
multiple network_ids is subject to exhaustive verification and is discouraged. 
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3) 256 network_ids values are reserved for private/temporary use. Their allocation is not subject of the ETSI 
standard. 

4) Network_ids will be allocated according to table 4. 

5) Network_ids for the terrestrial delivery medium will be made available to the appropriate national 
telecommunications regulator and their allocation in each country is under responsibility of this regulator. 

6) In order to avoid the uneconomical use of network_ids, the values will be given in blocks of 256 values on a 
country by country basis. Non-allocated network_ids will be kept reserved. 

7) The allocation of terrestrial network ids shall be based on a 4-colour-map approach (see annex B). Two blocks 
of 256 values are reserved for the eventual case of collision. 

8) If 256 values are not sufficient for a country, a new block of 256 colours will be allocated. This block can be 
used by all countries with the same colour in the colour map. 

NOTE: Due to the re-usable allocation of all types of network_id values (satellite, cable and terrestrial), no link 
between network_id and original_network_id exists. 

The schemes and values given in tables 4 and 5 shall be used for allocating network_id values. 

Table 4: Top-level Networkjd allocation template 



Network id 


Description 


Network type 


Country code(s) validity 


Comment 


0x0000 


Reserved 




all 


Reserved 


0x0001 to 0x2000 


Unique satellite 


Satellite 


902 


(4 096 values) 


0x2001 to 0x3000 


Unique terrestrial 


Terrestrial 


902 


(4096 values) 


0x3001 to 0x3100 


Re-useable terrestrial 


Terrestrial 


Countries of colour A 


(256 values) 


0x3101 to 0x3200 


Re-useable terrestrial 


Terrestrial 


Countries of colour B 


(256 values) 


0x3201 to 0x3300 


Re-useable terrestrial 


Terrestrial 


Countries of colour C 


(256 values) 


0x3301 to 0x3400 


Re-useable terrestrial 


Terrestrial 


Countries of colour D 


(256 values) 


0x3401 to 0x3500 


Re-useable terrestrial 


Terrestrial 


Countries of colour "E" 
(to be used only in case 
of collision) 


(256 values) 


0x3501 to 0x3600 


Re-useable terrestrial 


Terrestrial 


Countries of colour "F" 
(to be used only in case 
of collision) 


(256 values) 


0x3601 to OxAOOO 


Reserved for future use 


Terrestrial 




(27 136 values) 


OxAOOl to OxBOOO 


Re-useable cable 


Cable 


To be specified 


(4 096 values) 


OxBOOl to OxFOOO 


Reserved for future use 


Cable 




(16 384 values) 


OxFOOl to OxFFOO 


Unique cable 


Cable 


all 


(3 840 values) 


OxFECO to OxFFOO 


Network Interface 
Modules 


DVB Common 
Interface 


all 


(64 Values 


OxFFOI to OxFFFF 


Temporary private use 


Not defined 


all 


(255 values) 



Table 5: Detailed Networkjd allocation templates 



Networkjd 


Description 


Network type 


Country code(s) of 
validity 


Operator 


0x0001 to 0x2000 


Unique satellite 


Satellite 


all 


Satellite Operator 


0x0000 


Reserved 


all 


all 




0x0001 to 0x2000 


Reserved for registration through the DVB Project 
(see httD://www.dvb.ora) 



0x2001 to 0x3000 



Unique terrestrial 



Terrestrial 



all 



Terrestrial Operator 



0x2001 to 0x3000 



Reserved for registration through the DVB Project Office 
(see http://www.dvb.orq) 
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0x3001 to 0x3100 


Re-useable terrestrial 


Terrestrial 


Countries of 
Colour A 


(256 Values) 


0x3001 to 0x3100 


Reserved for registration through the DVB Project 
(see httD://www.dvb.ora) 



0x3101 to 0x3200 


Re-useable terrestrial 


Terrestrial 


Countries of 
Colour B 


(256 Values) 


0x3101 to 0x3200 


Reserved for registration through the DVB Project Office 
(see http://www.dvb.ora) 



0x3201 to 0x3300 


Re-useable terrestrial 


Terrestrial 


Countries of 
Colour C 


(256 Values) 


0x3201 to 0x3300 


Reserved for registration through the DVB Project 
(see http://www.dvb.ora) 



0x3301 to 0x3400 


Re-useable terrestrial 


Terrestrial 


Countries of 
Colour D 


(256 Values) 


0x3301 to 0x3400 


Reserved for registration through the DVB Project 
(see httD://www.dvb.ora) 



0x3401 to 0x3500 


Re-useable terrestrial 


Terrestrial 


Countries of 
Colour "E" - to be 
used only in case 
of colision 


(256 Values) 


0x3401 to 0x3500 


Reserved for registration through the DVB Project 
(see http://www.dvb.ora) 



0x3501 to 0x3600 


Re-useable terrestrial 


Terrestrial 


Countries of 
Colour "F" - to be 
used only in case 
of colision 


(256 Values) 


0x3501 to 0x3600 


Reserved for registration through the DVB Project 
(see http://www.dvb.ora) 



0x3601 to OxAOOO 


Reserved for future 
use 


Terrestrial 


To be defined 


(27 136 Values) 


0x3601 to OxAOOO 


Reserved for registration through the DVB Project 
(see httD://www.dvb.ora) 



OxAOOl to OxBOOO 


Re-useable cable 


Cable 


Country code(s) of 
validity 


(4 096 Values) 


OxAOOl to OxBOOO 


Reserved for registration through the DVB Project 
(see http://www.dvb.ora) 



0x8001 to OxFOOO 


Reserved for future 
use 


Cable 


To be defined 


(16 384 Values) 


OxBOOl to OxFOOO 


Reserved for registration through the DVB Project 
(see httD://www.dvb.ora) 



OxFOOl to OxFFOO 


Unique cable 


Cable 


Country code(s) of 
validity 


(3 840 Values) 


OxFOOl to OxFEBF 


Reserved for registration through the DVB Project 
(see httD://www.dvb.ora) 


OxFECO to FFOO 


Network Interface 
IVIodules 


Common 
Interface 


all 


64 Values 
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OxFFOI to OxFFFF 


Temporary_use 


Network_type 


Country code(s) of (255 Values) 
validity 


OxFFOI to OxFFFF 


Private temporary use 


Not defined 


all 


User defined 



5.3 Bouquetjd 



Bouquet_id values shall be allocated to broadcasters and network operators to identify bouquets within the application 
area of EN 300 468 [1], by insertion in the bouquetjd field. 

Table 6: Bouquetjd registration template 



Reistration field 


Required 


Description 


Bouquet ID 


optional 


ID according to the template below 


Bouquet Name 


required 


Name of the Bouquet (e.g. "ACME Pay-TV Service") 


Bouquet Country Code 


required 


Country code where the bouquet is unique (e.g. North 
America) 


Bouquet Operator 


required 


Name of company which operates Bouquet (e.g. "ACME 
Pay-TV, Inc.") 


Bouquet Legal Contact 


required 


Name and e-mail of authorized legal signatory of 
"Bouquet Operator" 


Bouquet Technical Contact 


required 


Name and e-mail of technical contact of "Bouquet 
Operator" 


Bouquet Notes 


optional 


Notes on the application, e.g. last revised and what 
revisions were made 



The Bouquet ID field in the registration template is to be seen as a proposal by the Applicant. The Registrar is not 
required to follow this suggestion and may assign a different value. In this case, the Applicant should be provided with 
a rationale for not having assigned the proposed bouquet_id value. 

The scheme and values given in table 7 shall be used for the allocation of bouquet_id values. 

Table 7: Bouquetjd allocation template 



Bouquetjd 


Bouquet name 


Country Code of 
Validity 


Bouquet operator 


0x0000 


Reserved 


all 


Reserved 


0x0001 to OxFFFF 


Reserved for general registration through the DVB Project 
(see httD://www.dvb.ora) 



5.4 CA_system_id 



CA_systemJd values shall be allocated to Conditional Access system vendors to identify CA sytems within the 
application area of EN 300 468 [1], by insertion in the CA_systemJd field. 

Table 8: CA_systemJd registration template 



Reistration field 


Required 


Description 


CA System ID 


optional 


ID according to the template below 


CA System Name 


required 


Name of the company supplying Conditional Access 
services (e.g. "ACME CA Services, Inc.") 


CA System Legal Contact 


required 


Name and e-mail of authorized legal signatory of "CA 
System Name" 


CA System Technical Contact 


required 


Name and e-mail of technical contact of "CA System 
Name" 


CA System Notes 


optional 


Notes on the application, e.g. last revised and what 
revisions were made 



ETSI 



13 



ETSI TS 101 162 VI .2.1 (2009-07) 



The CA System ID field in the registration template is to be seen as a proposal by the Applicant. The Registrar is not 
required to follow this suggestion and may assign a different value. In this case, the Applicant should be provided with 
a rationale for not having assigned the proposed CA_system_id value. 

The scheme and values given in table 9 shall be used for allocation of CA_system_id values. 



Table 9: CA_systemJd allocation template 



CA system id values 


CA system specifier 


0x0000 


Reserved 


0x0001 to OxOOFF 


Reserved for registration to standardized systems through the 

DVB Project 

(see http://www.dvb.ora) 


0x0100 to OxFFFF 


Reserved for general registration through the DVB Project 
(see httD://www.dvb.ora) 



In the standardized systems registration range, allocations shall only be made for Conditional Access systems which are 
defined as such by an appropriate DVB authority, and which are fully described in a publicly available document from a 
recognized standardization body. 

In the general registration range allocations shall only be made to bone fide Conditional Access system vendors. 
Applicants need to demonstrate that the vendor is proposing a registration for a legitimate Conditonal Access product. 



5.5 Country code values 



Country_code values shall be allocated to geographical areas to identify groups of countries or parts of countries within 
the application area of EN 300 468 [1]. These are supplementary to ISO 3166 [5]. This identifier helps in defining 
geographical coverage of other identifiers. 

Table 10: Country_code registration template 



Reistration field 


Required 


Description 


Country Code 


optional 


ID according to the template below 


Geographical Area Name 


required 


Name of the geographical area (e.g. "North 
America") 


Geographical Area Legal Contact 


required 


Name and e-mail of authorized legal signatory of 
"Geographical Area Name" 


Geographical Area Technical Contact 


required 


Name and e-mail of technical contact of 
"Geographical Area Name" 


Geographical Area Notes 


optional 


Notes on the application, e.g. last revised and what 
revisions were made 



The Country Code field in the registration template is to be seen as a proposal by the Applicant. The Registrar is not 
required to follow this suggestion and may assign a different value. In this case, the Applicant should be provided with 
a rationale for not having assigned the proposed country_code value. 

The scheme and values given in table 1 1 shall be used for allocation of country_code values. 



Table 11 : Country code allocation template 



Code 


Grouping 


000 to 899 


Reserved for ISO 3166 [5] use 


900 to 999 


Reserved for registration through the DVB Project 
(see httD://www.dvb.ora) 



Due to the dact that geographical areas are ot be represented by this identifier, allocations of country_code values shall 
only be made to bone fide organistaions. Applicants need to demonstrate that they represent the geographical area in 
question in an appropriate way. Preferred Applicants for country_code_values are hence organization kown to be in 
agreement with the legal and regulatory authorities and other determining organizations active in or substantially 
affected by the area for which a country_code value is ot be registered. 
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5.6 Private data specifier values 



Private_data_specifier values shall be allocated to broadcasters, manufacturers and network operators and content 
producers to identify private SI elements within the application area of EN 300 468 [1], by insertion in the field 
private_data_specifier. 

Table 12: private_data_specifier registration template 



Reistration field 


Required 


Description 


Private Data Specifier 


optional 


ID according to the template below 


Private Data Specifier Organization 


required 


Name of the company or organization which is 
responsible for the character set described above 
(e.g. "ACME Fonts, Inc.") 


Private Data Specifier Legal Contact 


required 


Name and e-mail of authorized legal signatory of 
"Encoding Type ID" 


Private Data Specifier Contact 


required 


Name and e-mail of technical contact of "Encoding 
Type ID" 


Private Data Specifier Notes 


optional 


Notes on the application, e.g. last revised and what 
revisions were made 



The Private Data Specifier field in the registration template is to be seen as a proposal by the Applicant. The Registrar is 
not required to follow this suggestion and may assign a different value. In this case, the Applicant should be provided 
with a rationale for not having assigned the proposed private_data_specifier value. 

The scheme and values given in table 13 shall be used for allocating private_data_specifier values. 



Table 13: Private data specifier values 



Private data specifier values 


Organization specifying private SI codes 


0x00000000 


Reserved 


0x00000001 to OxFFFFFFFF 


Reserved for general registration through the DVB Project 
(see http://www.dvb.ora) 



Since the private_data_specifier plays important roles in national broadcast regulations and service aggregation, being 
able correctly identify the origins of the private data is important. Hence, private_data_specifier values shall only be 
allocated to bona fide organizations for which there is a legal signatory. 



5.7 



Data broadcast id 



Data_broadcast_id values shall be allocated to broadcasters. Conditional Access vendors, middleware vendors and other 
standardization bodies to identify the types of Data Broadcast services within the application area of EN 300 468 [1], by 
insertion in the field data_broadcast_id. 

Table 14: data_broadcastJd registration template 



Reistration field 


Required 


Description 


Data Broadcast ID 


optional 


ID according to the template below 


Data Broadcast Specification Name 


required 


Name of a Data Broadcast Specification (e.g. 
"ACMEcastl.O") 


Data Broadcast Specifier 


required 


Name of the company specifying the "Data 
Broadcast Specification Name" mentioned above 
(e.g. "ACMEcast, Inc.") 


Data Broadcast Legal Contact 


required 


Name and e-mail of authorized legal signatory of 
"Data Broadcast Specifier" 


Data Broadcast Technical Contact 


required 


Name and e-mail of technical contact of "Data 
Broadcast Specifier" 


Data Broadcast Notes 


optional 


Notes on the application, e.g. last revised and what 
revisions were made 
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The Data Broadcast ID field in the registration template is to be seen as a proposal by the Applicant. The Registrar is 
not required to follow this suggestion and may assign a different value. In this case, the Applicant should be provided 
with a rationale for not having assigned the proposed data_broadcast_id value. 

The scheme and values given in table 15 shall be used for allocation of data_broadcast_id values. 

Table 15: Data_broadcast_id allocation template 



Data broadcast id 


Data broadcast specification 


0x0000 


Reserved for future use 


0x0001 to OxOOEF 


Reserved for registration to DVB data broadcasting 


0x0001 


Data pipe 


0x0002 


Asynchronous data stream 


0x0003 


Synchronous data stream 


0x0004 


Synchronized data stream 


0x0005 


IVIuIti protocol encapsulation 


0x0006 


Data Carousel 


0x0007 


Object Carousel 


0x0008 


DVB ATM streams 


0x0009 


Higher Protocols based on asynchronous data streams 


OxOOOA 


System Software Update service [8] 


OxOOOB 


IP/MAC Notification service [2] 


OxOOOC to OxOOEF 


Reserved for future use by DVB 


OxOOFO to OxOOFF 


Reserved for registration to MHP data broadcasting 


0x0100 to OxFFFE 


Reserved for general registration through the DVB Project 
(see httD://www.dvb.ora) 


OxFFFF 


Reserved for future use 



In the general registration range separate allocations for different versions of the same data broadcast specification shall 
only be made if and when a receiver would otherwise not be able to detect the version used from the contents of the data 
broadcast streams themselves or from private data carried in DVB -SI descriptors bearing a data_broadcast_id field. 
Data broadcast specifiers are thus encouraged to design their specifications such that receivers can detect the version 
used without the use of separate data_broadcast_id values. 



5.8 



Platform id 



Platform_id values shall be allocated to network operators and IPDC platform operators to uniquely identify the 
IP/MAC platform in use which is defined in EN 301 192 [2], by insertion in the platform_id field. 

Table 16: Platformjd registration template 



Reistration field 


Required 


Description 


Platform ID 


optional 


ID according to the template below 


Platform Name 


required 


Name of the IP/MAC Platform (e.g. "ACME 
MobileTV"). 


Platform Operator 


required 


Name of company which operates IP/MAC Platform 
(e.g. "ACME Mobile Com, Inc.") 


Platform Legal Contact 


required 


Name and e-mail of authorized legal signatory of 
"Platform Operator" 


Platform Technical Contact 


required 


Name and e-mail of technical contact of "Platform 
Operator" 


Platform Notes 


optional 


Notes on the application, e.g. last revised and what 
revisions were made 



The Platform ID field in the registration template is to be seen as a proposal by the Applicant. The Registrar is not 
required to follow this suggestion and may assign a different value. In this case, the Applicant should be provided with 
a rationale for not having assigned the proposed platform_id value. 

The scheme and values given in table 17 shall be used for allocating platform_id values. 
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Table 17: Allocation of platformjd values 



Platform id 


Owner 


0x000000 


Reserved 


0x000001 to OxFFEFFF 


Reserved for general registration through the DVB Project 

(see httD://www.dvb.ora). 

These platform id values are globally unique. 


OxFFFOOO to OxFFFFFE 


Managed by the network operator, and may be used for IP/MAC 
Platforms supporting services only within a single DVB network. 
These platformjd values are unique within a networkjd only. 


OxFFFFFF 


Reserved 



5.9 CP_system_id 



CP_system_id values shall be allocated to identify Copy Protection (CP) systems to which DVB-CPCM content will be 
exported within the application area of EN 300 468 [1], by insertion in the field CP_system_id. 

Table 18: CP_system_id registration template 



Reistration field 


Required 


Description 


CP System ID 


optional 


ID according to the template below 


CP System Description 


required 


Name of a Content Protection System 
(e.g. "ACME Content Safe 1 .0" 


CP System Specifier 


required 


Name of the company supplying the CPS 
(e.g. "ACME CPS Consortium") 


CP System Legal Contact 


required 


Name and e-mail of authorized legal signatory of 
"CP System Specifier" 


CP System Technical Contact 


required 


Name and e-mail of technical contact of "CP System 
Specifier" 


CP System Notes 


optional 


Notes on the application, e.g. last revised and what 
revisions were made 



The CP System ID field in the registration template is to be seen as a proposal by the Applicant. The Registrar is not 
required to follow this suggestion and may assign a different value. In this case, the Applicant should be provided with 
a rationale for not having assigned the proposed CP_system_id value. 

The scheme and values given in table 19 shall be used for allocation of CP_system_id values. 

Table 19: CP_system_id allocation template 



CP system id values 


CP system specifier 


0x0000 


DVB CPCM Content Licence 


0x0001 


DVB CPCM Auxiliary Data 


0x0002 


DVB CPCM Revocation List 


0x0003 to OxOOFF 


reserved for future use by DVB CPCM 


0x0100 to OxFFFF 


Reserved for general registration through the DVB Project 
(see http://www.dvb.ora) 



In the general registration range allocations shall only be made to bone fide Copy Protection system vendors. 
Applicants need to demonstrate that the vendor is proposing a registration for a legitimate Copy Protection product. 



5. 1 Encoding_type_id 



Encoding_type_id values shall be allocated to broadcasters, network operators and content producers to identify string 
encodings within the application area of EN 300 468 [1], by insertion in the field encoding_type_id in the second byte 
of the string. 
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Table 20: encoding_type_id registration template 



Reistration field 


Required 


Description 


Encoding Type ID 


optional 


ID according to the template below 


Encoding Type Description 


required 


Name of a character encoding type (e.g. "ACME 
Universal Character Set 3") 


Encoding Type Specifier 


required 


Name of the company or organization which is 
responsible for the character set described above 
(e.g. "ACME Fonts, Inc.") 


Encoding Type Legal Contact 


required 


Name and e-mail of authorized legal signatory of 
"Encoding Type ID" 


Encoding Type Technical Contact 


required 


Name and e-mail of technical contact of "Encoding 
Type ID" 


Encoding Type Notes 


optional 


Notes on the application, e.g. last revised and what 
revisions were made 



The Encoding Type ID field in the registration template is to be seen as a proposal by the Applicant. The Registrar is 
not required to follow this suggestion and may assign a different value. In this case, the Applicant should be provided 
with a rationale for not having assigned the proposed encoding_type_id value. 

The scheme and values given in table 21 shall be used for allocation of encoding_type_id values. 

Table 21 : encoding_type_id 



encoding type id values 


Organization 


0x00 


Reserved 


0x01 to OxEF 


Reserved for general registration through the DVB Project 
(see httD://www.dvb.ora) 


OxFO to OxFF 


Reserved for future use 



5.1 1 Generic Stream Transport Layer Protocol Signaling 

The DVB-S2, -T2 and -C2 physical layers provide Generic Stream modes for conveying arbitrary, variable length 
payload frames. To identify the type of payload frames, a field in the header of these physical layers is used. 
For example, in the case of DVB-S2 and -T2, the SYNC field is used. Further details about the fields used can be found 
in [6]. 

Table 22: Generic Stream Protocol Type registration template 



Reistration field 


Required 


Description 


Protocol Type ID 


optional 


ID according to the template below 


Protocol Type Description 


required 


Name of protocol specification (e.g. "ACME SkyDSL") 


Protocol Type Specifier 


required 


Name of the company or organization which is 
responsible for the protocol specification above 
(e.g. "ACME Sat Coms, Inc.") 


Protocol Type Legal Contact 


required 


Name and e-mail of authorized legal signatory of 
"Protocol Type ID" 


Protocol Type Technical Contact 


required 


Name and e-mail of technical contact of "Protocol Type 
ID" 


Protocol Type Notes 


optional 


Notes on the application, e.g. last revised and what 
revisions were made 



The Protocol Type ID field in the registration template is to be seen as a proposal by the Applicant. The Registrar is not 
required to follow this suggestion and may assign a different value. In this case, the Applicant should be provided with 
a rationale for not having assigned the proposed Protocol Type value. 

The scheme and values given in table 23 shall be used for allocation of Protocol Type values. 
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Table 23: Generic Stream Protocol Types allocation template 



Protocol Type 


Definition 


0x00 


Generic Stream Encapsulation [6] 


0x01 to 0xB8 


Reserved for registration to standardized protocols through the DVB 

Project 

(see httD://www.dvb.ora) 


0xB9 to OxFF 


user private 



In the standardized protocols registration range, allocations shall only be made for standard protocols which are defined 
as such by DVB Project, and which are fully described in a publicly available document from a recognized 
standardization body. 
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Annex A (informative): 

Example Scenarios for the Utilization of networkjd and 

original_network_id 



A.1 Re-transmission of a satellite signal in terrestrial 
networks 

A service operator A-TV transmits his transport stream to satellite X-SAT. The signal is re-transmitted by the terrestrial 
network A-NET in country A with modifications to the content. The signal is re-transmitted by the terrestrial 
network in country B without modifications to the content: 

• A-TV has the unique original_network_id 0x1234. 

• Another television network B-TV (original_network_id = 0x5678) is using the same satellite for the 
contribution to A-Net in country A and to B-Net in country B. 

• The original_network_id of a DVB-T network is very likely to be the one given for that country according to 
table 1 of the present document. The originating service operator and its original_network_id in this case do 
not occur in the NIT of terrestrial networks. 

• X-SAT has the network_id 0x0200 (in range of unique satellite networks). 

• A-NET and B-Net share the re-usable terrestrial network_id range of 0x3300 to 0x334f. 



Service operator 
A-TV 

orig_nw_id = 
0x1234 




- - nw id = 0x200 



l:^ 



NIT 

nwjd = 0x0200 

nw_name="X-SAT" 

transp_stream_id=1 

orig_nw_id = 0x1 234 
transp_stream_id=2 

orig_nw_id = 0x5678 



NIT 

nwJd = 0x3322 

nw_name="A-NET" 

transp_stream_id=1 1 

orig_nw_id = 0x1 1 1 1 
transp_stream_id=2 1 

orig_nw_id = 0x1 1 1 1 



A 



Service operator 
B-TV 

orig_nw_id = 
0x5678 



country B 




transp_stream_id=2 
orig_nw_id = 0x5678 




country A 



NIT 

nwJd = 0x3304 

nw_name="A-NET" 

transp_stream_id=1 2 

orig_nw_id = 0x1 1 1 1 
transp_stream_id=22 

orig_nw_id = 0x1 1 1 1 



Figure A.1 

The satellite NIT contains the original_network_id of A-TV and the network_id of X-SAT. 
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On the terrestrial network the original_network_id has always the value that has been allocated for a certain country by 
Table 1 of the present document. The network_id is replaced by one of the network_ids of country A that could be re- 
used in country B if it has the same colour in the colour-map (see annex B). 



A.2 Re-transmission of a satellite signal in cable 
networks 

The same scheme as above applies. Cable networks generally can use re-usable network_ids because there is no risk 
that IRDs are connected to two cable networks sharing the same network_id at the same time. 

The satellite serves different cable networks in L-Town and in E-Town. They can use the same network_id because they 
are physically separated. 

A special case is the transmission of cable network NITs as "foreign" NITs on a satellite. In this case the cable 
network_ids have to be in the unique range of values since a collision on other networks using the same re-usable 
network_id cannot be guaranteed. Note that this method is not recommended since the number of unique 
networkjds is hmited. 



X-SAT - - nw_id = 0x200 




Service Operator 

A-TV 

orig_nw_id = 0x1234 



I NIT 

|nw_id = 0x200 
I nw_name="X-S AT" 
I transp_stream_id= 1 
I orig_nw_id = 0x1234 
transp_stream_id=2 
orig_nw_id = 0x5678 



Service Operator 

B-TV 

orig_nw_id = 0x5678 




NIT 

nw_id = 0xA100 
nw_name="LTowncable" 
transp_stream_id= 1 

orig_nw_id = 0x1234 
transp_stream_id=2 

orig_nw_id = 0x5678 



country A 



INIT 

nw_id = 0xA100 
\ nw_name="ETo wnC able' ' 
I transp_stream_id= 1 
I orig_nw_id = 0x1234 
I transp_stream_id=2 
orig_nw_id = 0x5678 



Figure A.2 
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Annex B (informative): 

Colour IVIap for the allocation of terrestrial networkjds 

The allocation of network_ids in terrestrial networks needs to be coordinated between geographically neighbouring 
network operators to enable terminals to reliably acquire a service near network boundaries. Within countries this is 
typically handled by national regulatory bodies. To support coordination between countries, DVB uses an allocation 
scheme based on colour-maps under which a colour is associated with each range of network_id values. Another 
country is only assigned values of the same colour if other countries of this colour are geographically distant enough to 
not radiate any overlapping terrestrial broadcasts. Figure 1 below shows the allocation of colours to network_id ranges 
and countries as of this writing. 




D/sa 

TERRESTRIAL 



■ 0x3601 - 0x3700 

■ 0x3501 - 0x3600 

■ 0x3401 -0x3500 

■ 0x3301-0x3400 
0x3201 - 0x3300 

■ 0x3101-0x3200 
I 0x3001 -0x3100 
n Unallocated 



(Colour F) 
(Colour E) 
(Colour D) 
(Colour C) 
(Colour B) 
(Colour A) 



\P are registered trademarks of the DVB Project 



Updated March 2006 



Figure B.1 : Colour map for allocating networkjds in terrestrial networks 
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